fix(explorer): show Created timestamp for addresses #500
+212
−15
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bundle Size Report
Chunk changes (>1KB)
Compared against main branch (baseline from 1/23/2026, 3:40:56 AM) |
Cloudflare Deployments
|
The Created field was always showing '...' because: 1. totalTransactions was hardcoded to 0 2. The oldest transaction query was disabled (enabled: totalTransactions > 0) Fix: Use sort=asc with limit=1 to directly fetch the oldest transaction instead of trying to calculate the last page offset. This adds the 'sort' parameter to transactionsQueryOptions and uses it in AccountCardWithTimestamps to fetch the first (oldest) transaction. Note: For contracts, the creation transaction may not appear if the IndexSupply query doesn't include it (since contractAddress is in the receipt, not the tx). A follow-up could address this by querying for contract creation txs specifically.
For contracts with no transaction history, the Created field was showing '...' because there were no transactions to derive the timestamp from. This adds a new API endpoint /api/contract/creation/$address that: 1. Checks if the address is a contract (has bytecode) 2. Uses binary search to find the creation block 3. Returns the block number and timestamp The AccountCardWithTimestamps component now: - First tries to get the oldest transaction timestamp (for addresses) - Falls back to the contract creation API for contracts without txs This fixes the issue where https://explore.tempo.xyz/address/0x0000f90827f1c53a10cb7a02335b175320002935 showed '...' for Created because the contract creation tx wasn't in the transaction history (IndexSupply only indexes from/to, not contractAddress). Amp-Thread-ID: https://ampcode.com/threads/T-019be242-b261-775a-be3c-4afeef66f51b Co-authored-by: Amp <amp@ampcode.com>
The binary search was taking ~40 seconds due to slow historical RPC calls. Optimizations: - Add in-memory cache to avoid repeated lookups for the same contract - Parallelize the final batch of block checks - Start search from block 1 instead of 0 This significantly improves response time for repeated requests.
o-az
force-pushed
the
fix/contract-creation-display
branch
from
c739a0f to
64e3016
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bug Report
Contract address pages (e.g., https://explore.tempo.xyz/address/0x0000f90827f1c53a10cb7a02335b175320002935) show "..." for the Created field.
Reported by Dan: https://tempoxyz.slack.com/archives/C0A87C21805/p1769027575403559
Root Cause
In
AccountCardWithTimestamps, the logic to fetch the oldest transaction was broken:Since
totalTransactionswas hardcoded to 0, the query to fetch the oldest transaction was never enabled.Fix
Use
sort=ascwithlimit=1to directly fetch the oldest transaction, instead of trying to calculate the last page offset:Changes:
sortparameter totransactionsQueryOptionssort: 'asc'inAccountCardWithTimestampsto fetch the oldest transactiontotalTransactions/enabledlogicLimitations
For newly created contracts, the creation transaction itself may still not appear in the transaction list because the IndexSupply query in
/api/address/$addressonly searchesfromandtofields. Contract creation transactions haveto: nulland store the contract address in the receipt'scontractAddressfield.A follow-up could:
contractAddressmatches